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(1) Real party in interest 

The real party in interest is Virtualagility, Inc., a Delaware corporation having a place of 
business at 17 Lakeview Rd., Winchester, MA 01890. 

25 

(2) Related appeals and interferences 

The present patent application is a CIP of USSN 09/312,740, Beaven, Processing 
management information, filed 5/14/99. A Notice of Appeal and a Pre-appeal Brief 
30 Request for Review were filed in the parent on 8/20/2007. 

(3) Status of claims 

Claims 4-10 and 37-43 are pending in the application. All claims stand rejected. The 
only independent claim is claim 37. Claim 37 has been rejected as obvious over the 
35 combination of U.S. Patent 6,157,915, Bhaskaran, et al., Method and apparatus for 
collaboratively managing supply chains, filed Aug. 7, 1998 and Official Notice that "it is 
old and well-known in the art to submit a model to be executed by a processor" (Final 
rejection of 1 1/30/2006, p.6). The rejection of claim 37 of course applies equally to 
dependent claims 4-10 and 38-43. Additionally, however, Examiner has found the added 
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limitations of claims 4 and 5 in Bhaskaran. Examiner has not found the added limitations 
of claim 6-10 in Bhaskaran, but regards the added limitations as "descriptive material 
[that] will not distinguish the claimed invention from the prior art in terms of 
patentability" (Final rejection of 1 1/30/2006, p, 4). Examiner finds the added limitations 
5 of claims 38 and 41-43 in Bhaskaran. In claim 39, Examiner combines Official Notice 
that "a second visible part which shows specific detailed information from the first 
visible part is old and well known in the art" (rejection of 11/30/2006, p. 8) with the 
grounds for the rejection of claim 37. Claim 43 is a Beauregard claim dependent from 
claim 37, and as such, its patentability depends completely on the patentability of claim 
10 37. 

Examiner has objected to claim 43, which is a dependent Beauregard claim, as being of 
improper dependent form "for failing to further limit the subject matter of a previous 
claim". 

15 

(4) Status of amendments 

The claims stand as amended on 8/7/2006. No later amendments have been filed. 

(5) Summary of claimed subject matter 

20 Overview of Applicants 9 system for performing collaborative tasks 

Applicants' system for performing collaborative activities permits collaborators to see 
and modify a model of the collaborative activity. The model is made up of at least goal 
model entities which represent goals and/or projects of the activity and initiative model 
entities which relate goal model entities across the model. The initiative model entities 

25 and the goal model entities are arranged in hierarchies and a goal model entity may also 
belong to an initiative hierarchy. A graphical user interface permits collaborators to view 
the model entities in their hierarchies, view the model entities in detail, modify the 
hierarchies and the model entities, and access information via the model entities. FIG. 
41, described beginning at page 28, line 10, provides an overview of an example model 

30 and its entities and FIG 46, described beginning at page 36, linel3, provides an overview 
of the graphical user interface. Particularly important aspects of Applicants' invention 
are the following: 
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• The model is visible to the collaborators; each collaborator can consequently see how 
what he or she does relates to the entire collaborative activity, 

• The model is made by and is modifiable by the collaborators. The model thus exactly 
fits the collaboration and when properly maintained by the collaborators, the model 

5 shows the current state of the collaborative activity. 

• The goal and initiative hierarchies give the collaborators different views of the model 
The only independent claim is claim 37. Applicants have added reference numbers to 
map the claim limitations to the Specification. In the reference numbers, the digits other 
than the two right-hand digits are figure numbers. An item indicated by the reference 

10 number 4009, for example, is shown in FIG. 40. The reference numbers are provided for 
the aid of the Board and are not intended to limit the claim. 



1 37. A system for supporting management of a collaborative activity by 

2 persons involved therein, the persons not being specialists in information 

3 technology and the system comprising: 

4 a representation (4201) of a model (4101) of the collaborative 

5 activity, the representation being accessible to a processor, the model of 

6 the collaborative activity including model entities (4009, 4109, 4013, 

7 40 1 5) that are organized into hierarchies (401 1, 41 1 1) and provide access 

8 to information (4017) concerning the collaborative activity, 

9 the model entities having types including 

10 a goal model entity type (4013), model entities of the type 

1 1 representing goals and/or projects of the collaborative activity and 

12 an initiative model entity type (4109), model entities of the 

13 type serving to relate goal model entities across the model, and 

14 the hierarchies including 

15 a goal hierarchy (4011) whose members include at least 

16 one goal model entity, a given goal model entity belonging to only a 

17 single goal hierarchy and 

18 an initiative hierarchy (4111) whose members include at 

19 least one initiative model entity, each initiative model entity being capable 

20 of having as children one or more initiative model entities and/or one or 

21 more goal model entities from one or more of the goal hierarchies; and 

22 a graphical user interface for the system (4601) which the 

23 processor provides to the persons, the graphical user interface permitting a 

24 person of the persons to perform operations on a model entity including 

25 creating (5001), modifying (p. 20, line 20), and/or deleting (p. 20, line 30) 

26 the model entity, assigning the model entity to a parent in a hierarchy 

27 (4701), accessing and/or modifying the information concerning the 

28 collaborative activity via the model entity (4625), and viewing model 

29 entities in a hierarchy of the hierarchies to which the model entities belong 

30 (4613). 
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The model 4101 of the invention is described in FIGs. 40 and 41; the description of FIG. 
40 begins at 25, line 40, that of FIG. 40 begins at page 28, line 10; the representation 
4201 of the model is described beginning at page 29, line 11; the graphical user interface 
4601 is described beginning at page 36, line 1 1. FIGs. 47 and 50 are discussed beginning 
5 at page 40, line 15. 

(6) Grounds of rejection to be reviewed on appeal 

The grounds of rejection to be reviewed on appeal are the following: 

• the rejection of claims 37, 43, and 4-10 as obvious over the combination of U.S. 
10 Patent 6,157,915, Bhaskaran, et al., Method and apparatus for collaboratively 

managing supply chains, filed Aug. 7, 1998 (henceforth "Bhaskaran") and Official 
Notice that "it is old and well-known in the art to submit a model to be executed by a 
processor" (Final rejection of 1 1/30/2006, p.6). 

• The rejection of claims 6-10 on the grounds that the added limitations are "descriptive 
15 material [that] will not distinguish the claimed invention from the prior art in terms of 

patentability" (Final rejection of 1 1/30/2006, p. 4). 

• The rejection of claims 38 and 41-42 as obvious over Bhaskaran and Official Notice. 

• The rejection of claim 39, as obvious over Bhaskaran and Official Notice as above 
and the further Official Notice that "a second visible part which shows specific 

20 detailed information from the first visible part is old and well known in the art" 
(rejection of 1 1/30/2006, p. 8). 
The rejections of claim 37, 43, and 4-10 stand and fall together; the rejections of claims 
38-42 will be argued separately. 

25 (7) Argument 

The disclosure of Bhaskaran 

Bhaskaran discloses a system for coordinating the activities of entities making up a 
supply chain. An example of the kind of supply chain the system can be used with is 
shown in Bhaskaran's FIG. 1, discussed at col. 3, lines 44-67, Bhaskaran's system 
30 permits the entities in the supply chain to collaborate in determining how they will 
respond to events which affect the supply chain. The system has three main components: 
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• a supply capability engine (SCE) which is a constraint-based supply chain planning 
and optimization tool (col. 7, lines 55-58); 

• active documents which contain information to be input to the SCE (col. 5, lines 25- 
49, FIGs. 3, 3A, 4, 6) 

5 • interfaces for synchronous and asynchronous communications between the entities 
making up the supply chain (col. 6, line 46-col. 7, line 16, FIGs. 7 and 8). 
Operation of Bhaskaran's system is described at col, 7, line 40 through col. 8, line 49 and 
shown in the flowchart of FIG. 9. When an event happens which requires a change in the 
supply chain, the collaborator who has knowledge of the event notifies the other 

10 collaborators and initiates a scenario (S920). The scenario describes a rearrangement of 
the supply chain which deals with the event. The collaborators use the communications 
interfaces to discuss how to deal with the event and then use the active documents to 
describe the scenario that results from their discussions (FIG. 4, col. 6, lines 7-23). The 
SCE is then run on the active documents (S930). The collaborators then study the results 

15 returned by the SCE (S950), discuss them using the communications interface, and revise 
the scenario to deal with the problems indicated in the results from the SCE (S950). If 
the revisions are sufficient, a plan based on the scenario is submitted to the collaborators 
(S960). If the collaborators approve the plan (S970), the plan is published to the 
collaborators and the supply chain operates according to the approved plan. Otherwise, 

20 the scenario is again revised. If necessary, a new scenario is made (S965) using the 
active documents and the process begins again. 

Distinctions between Bhaskaran and Applicants ' system of claim 37 

The graphical user interface (GUI) of Bhaskaran is made up of windows for accessing 

25 and making active documents and running scenarios, (FIGs. 3, 3A, 4, and 6) and 
windows for communicating with the other collaborators (FIGs. 7 and 8). There is 
nothing in the GUI which shows hierarchical relationships between entities of the supply 
chain or between the active documents which are used to input information for scenarios 
and the GUI provides no operations for modifying such relationships. In particular, FIG. 

30 l's graph of the supply chain is not visible anywhere in the GUI. There is further is no 
disclosure in Bhaskaran that suggests in any way that his system includes a representation 
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in memory of the supply chain shown in FIG. L Indeed, given the way in which 
Bhaskaran's system works, such a representation would be completely superfluous. 

Examiner 's failure to establish a prima facie case of obviousness in his rejection of 
5 claims Hand 4-10 and 43 

Claims 4-10 and 43 stand and fall with claim 37. Examiner has rejected claim 37 as 
obvious over Bhaskaran combined with Official Notice that "it is old and well-known in 
the art to submit a model to be executed by a processor". As set forth at MPEP 2142, in 
order to make such a rejection, Examiner must make a prima facie case which shows, 
10 among other things, that the combination of references cited by Examiner discloses all of 
the limitations of the claim under rejection. As one would expect from the foregoing 
discussion of the distinctions between Bhaskaran, when claim 37 is compared with the 
disclosure of Bhaskaran, it is clear that Examiner has not made his prima facie case: 

♦ there is no disclosure of the claim's "representation (4201) of a model (4101) of the 
15 collaborative activity, the representation being accessible to a processor, the model of 

the collaborative activity including model entities (4009, 4109, 4013, 4015) that are 
organized into hierarchies" 

♦ There is further nothing disclosed in Bhaskaran that can reasonably be termed an 
entity that has a "goal model entity type" or an entity that has an "initiative model 

20 entity type". 

• Since there is no disclosure of model entities that are organized into hierarchies or 
have the foregoing types, there can be and is no disclosure of the goal and initiative 
hierarchies defined at lines 16-22 of claim 37. 

• Because there is no disclosure of model entities that are organized into hierarchies 
25 there can be and is no disclosure of a graphical user interface which u permit[s] a 

person to perform operations on a model entity including ... assigning the model 
entity to a parent in a hierarchy ... and viewing model entities in a hierarchy of the 
hierarchies to which the model entities belong". 

Because Bhaskaran discloses none of the foregoing limitations of claim 1, the 
30 combination of Bhaskaran and Official Notice does not disclose all of the limitations of 

claim 37, Examiner has not made the prima facie case required for a rejection under 35 
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U.S.C. 103, Claims 4-10 and 43 are of course not obvious over Bhaskaran and Official 
Notice because claim 37 is not obvious over Bhaskaran and Official Notice. 

Detailed rebuttal of Examiner % s rejection of claim 37 

5 Examiner deals with claim 37's "representation of the model" as follows: 

Bhaskaran teaches a method which represents a model to manage supply 
chain activities. Figure 1 shows a model of how the organization of the 
entities within the supply chain system are hierarchically linked" (Office 
action of 5/14/2007, p! 3) 

10 

As set forth above, FIG. 1 simply shows an example supply chain; there is no suggestion 
whatever in Bhaskaran that his system has any "representation" of what is shown in FIG. 
1 that is "accessible to a processor", as required by the claim. 

15 Examiner finds Applicants 5 "model entities" in the participants in the supply chain of 
FIG. 1 and their hierarchical relationships in the vendor-distributor relationships (Office 
action of 5/14/2007, p. 3). Because there is no disclosure of any "representation of a 
model" of FIG. 1 in Bhaskaran, FIG. 1 cannot be taken as a disclosure of Applicants' 
claimed model entities or of the hierarchical relationships between them. As for a 

20 graphical user interface which permits the user to see or operate on the hierarchical 
relationships, Examiner merely asserts, "Bhaskaran further teaches a graphical user 
interface that allows user to manipulate data corresponding to each of these features" 
(Office action of 5/14/2007, p. 3). There is, however, nothing in any of Bhaskaran's 
FIGS. 2-4 and 6-8 which suggest that the relationships shown in FIG. 1 are visible in or 

25 manipulatable through Bhaskaran's GUI, as required by the claim. 

Examiner finds the "goal model entity type" and the "initiative model entity type" in the 
supply chain participants as follows: 

... the goal entity is the distributor. All other entities on this model 
30 promote work until it reaches the goal entity the distributor. (Office action 

of 5/14/2007, p. 7) 

... sub-assemblers and final assemblers are initiative model entity types 
that feed final products to the goal entity the distributors. (Office action of 
35 5/14/2007, p. 7) 
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These applications of the disclosure of Bhaskaran to claim 37 comport neither with the 
description of a "goal model entity" in the claim as "representing goals and/or projects of 
the collaborative activity" nor with the description of an 'initiative model entity" in the 
claim as "serving to relate goal model entities across the model" nor with the many, many 
examples of goals or projects and initiatives in Applicants' Specification and thus do not 
represent a reasonable reading of the language of claim 37. 

Examiner finds the operations which the GUI permits the user to perform on the model 
entity disclosed in Bhaskaran as follows: 

Users with the necessary permissions can create, modify, or delete 
business scenarios. In this case, a business scenario is the same as 
creating, modifying, or deleting a model entity included in the business 
scenario. When creating a business scenario the user can assign parent 
and child entities to the scenario. (Office action of 5/14/2007, p. 7) 

There is simply no disclosure in Bhaskaran of any graphical user interface which permits 
a user to create, modify, or delete a model entity representing an entity in a supply chain 
when creating a scenario or assign parent or child entities in the supply chain when 
creating a scenario. Indeed, the whole mechanism by which scenarios are created 
requires a fixed set of entities in the supply chain that collaborate in making the scenario. 
See the description of making scenarios at col. 7, line 42-col. 8, line 48 of Bhaskaran. 

The foregoing detailed examination of Examiner's grounds for rejecting claim 37 simply 
confirm what is obvious from even the most superficial comparison of the disclosure of 
Bhaskaran with Applicants' claim 37: Bhaskaran combined with Official Notice does not 
disclose all of the limitations of claim 37 and Examiner has consequently not made his 
prima facie case of obviousness. 

The lack of patentable distinctions in claims 6-10 

Examiner regards the added distinction in each of these claims as being non-functional 
descriptive material; Applicant's attorney respectfully disagrees. In the world of digital 
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systems, documents, messages, alerts, reminders, and discussions behave differently and 
are generally handled by different software modules. Consequently, when each of the 
claimed kinds of further information is added to Applicants' system, a functionally 
different system results. 

5 

The rejection of claim 38 

The additional limitations here are the domain model entity and the domain hierarchy; 

Examiner finds these limitations in Bhaskaran as follows: 

. . . sub-assemblers and final assemblers are domain model entity types that 
10 feed final products to the goal entity the distributors. Final assemblers 

have children entities such as the sub-assembler entities. 

As with the goal and initiative entities to claim 37, this application of the disclosure of 
Bhaskaran to claim 38 comport neither with the description of a "domain model entity" in 
15 the claim as "serving to relate goal model entities across the model" nor with the many, 
many examples of domains in Applicants' Specification and thus do not represent a 
reasonable reading of the language of claim 38. 

The rejection of claim 39 

20 The additional limitations of this claim address two elements of Applicants' GUI 4601: 
navigator menu 4607, which shows model entities in their hierarchies, and work area 
4619, described at page 36, lines 23-25. Examiner rejects the claim on the basis of 
Official Notice that "a second visible part which shows specific detailed information 
from the first visible part is old and well known in the art" (rejection of 1 1/30/2006, p. 8). 

25 The difficulty with the rejection is that as pointed out in the discussion of the rejection of 
claim 37 above, Bhaskaran does not disclose a graphical user interface which shows 
model entities in their hierarchies. 

The rejection of claim 40 
30 The additional limitation of this claim is that "any of the model entities is capable of 
providing access to information concerning the collaborative activity". As set forth in 
claim 37, the access is via the model entity as it appears in Applicants 5 GUI. Examiner 
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finds the added limitation in Bhaskaran's disclosure that "access control for each of the 
entities is set such that the entities can access and provide information in their relevant 
roles" (Office action of 5/14/2007, p. 10). This of course discloses nothing whatever 
about access to the information in the GUI via the model entity. In Bhaskaran, what can 
5 be accessed in the GUI are messaging facilities and active documents, and the user does 
not access these by first selecting a model entity in the GUI, as required by claim 40. 

The rejection of claim 41 

The added limitation here is the access control information which controls access by 
10 individuals to individual model entities. Examiner refers Applicants to Bhaskaran col. 6, 
lines 24-36. The difficulty with rejection is the following: in Examiner's interpretation 
of claim 37, the model entities are the entities of the supply chain; what Bhaskaran 
discloses is access privileges which control access to active documents and messaging 
interfaces, not access to entities in the supply chain, as required by the claim. The claim 
15 further requires that the access control operations performed via the GUI on the model 
entities, and as already described above, the entities of the supply chain do not appear in 
Bhaskaran's GUI 



The rejection of claim 42 
20 The added limitation in this claim is 

the operations which the graphical user interface performs includes 
viewing model entities as ordered by a value in the information concerning 
the collaborative activity to which the model entities give access. 

25 The claimed limitation is shown in FIG. 17 of Applicants' application, in which goals are 

ordered by their cost. See page 15, line 28-page 16, line 12. Examiner cites Bhaskaran, 

col, 6, lines 24-45 and then continues: 

the example given describes the order from one end of a supply chain 
starting at the supplier all the way to the goal entity the distributor. 
30 (Office action of 5/14/2007, p. 11) 

Col. 6, lines 24-45 describes Bhaskaran's access control system, which of course has 
nothing to do with what is set forth in claim 42; in the remainder of the rejection, 
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Examiner appears to be referring to Bhaskaran's FIG. 1, which of course is not visible in 
Bhaskaran's GUI Bhaskaran thus does not disclose the added limitation of the claim. 

The objection to claim 43 
5 The statutory provision governing dependent claims is 35 U.S.C. 1 12, fourth paragraph, 
which requires only that the dependent claim "contain a reference to a claim previously 
set forth and then specify a further limitation of the subject matter claimed". This 
requirement is restated by 37 C.F.R. 1 .75(c) and the relevant MPEP provisions. Claim 43 
satisfies the requirement: it refers back to claim 37 and claim 37 is further limited by the 
10 fact that what is claimed is not the system of claim 37, but rather a storage device that 
contains code which implements the system set forth in claim 37. Because claim 43 is 
permitted by 35 U.S.C 112, 4th paragraph, 37 C.F.R. 1.75(c), and the relevant MPEP 
provisions, Examiner's objection is without basis. 

15 Conclusion 

In the foregoing, Applicant has complied with the requirements of 37 C.F.R. 41.37 with 
regard to his brief and has demonstrated in the brief that Examiner has failed to establish 
a prima facie case of obviousness with regard to any of his rejections under 35 U.S.C. 
103. That being the case, the rejections cannot stand and Applicant respectfully requests 
20 that the Board of Appeals reverse the examiner with regard to all of his rejections and 
remand the application to Examiner for further processing as indicated by the reversals. 
The $250.00 fee for filing the brief accompanies the brief. No other fees are believed to 
be required. Should any be, please charge them to deposit account number 501 3 1 5. 

25 Respectfully submitted, 

/Gordon E. Nelson/ _ 
Attorney of record, 

30 Gordon E. Nelson 

57 Central St., P.O. Box 782 
Rowley, MA, 01969, 
Registration number 30,093 
Voice: (978)948-7632 
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(8) Appendix of claims 



3 



2 



4. 



The system set forth in claim 37 wherein: 

the model further includes representations of further information; and 
the interface permits the person to access the further information. 



5. 



The system set forth in claim 4 wherein: 

the interface further permits the collaborator to modify the further information. 



2 



2 



6. 



The system set forth in claim 5 wherein: 

the further information is a document that is accessible to the system. 



1 7* The system set forth in claim 5 wherein: 

2 the further information is a message sent to the collaborator by another 

3 collaborator. 

1 8. The system set forth in claim 5 wherein: 

2 the further information is an alert that indicates a change in the model that is 

3 relevant to the collaborator. 

1 9. The system set forth in claim 5 wherein: 

2 the further information is a reminder generated by the system for the collaborator. 

1 10, The system set forth in claim 5 wherein: 

2 the further information is a discussion concerning the model entity among the 

3 collaborators. 

1 37. A system for supporting management of a collaborative activity by persons 

2 involved therein, the persons not being specialists in information technology and the 

3 system comprising: 
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4 a representation of a model of the collaborative activity, the representation being 

5 accessible to a processor, the model of the collaborative activity including model entities 

6 that are organized into hierarchies and provide access to information concerning the 

7 collaborative activity, 

8 the model entities having types including 

9 a goal model entity type, model entities of the type representing goals 

10 and/or projects of the collaborative activity and 

11 an initiative model entity type, model entities of the type serving to relate 

12 goal model entities across the model, and 

1 3 the hierarchies i ncludi ng 

14 a goal hierarchy whose members include at least one goal model entity, a 

15 given goal model entity belonging to only a single goal hierarchy and 

16 an initiative hierarchy whose members include at least one initiative model 

17 entity, each initiative model entity being capable of having as children one or more 

18 initiative model enties and/or one or more goal model entities from one or more of the 

19 goal hierarchies; and 

20 a graphical user interface for the system which the processor provides to the 

21 persons, the graphical user interface permitting a person of the persons to perform 

22 operatons on a model entity including creating, modifying, and/or deleting the model 

23 entity, assigning the model entity to a parent in a hierarchy, accessing and/or modifying 

24 the information concerning the collaborative activity via the model entity, and viewing 

25 model entities in a hierarchy of the hierarchies to which the model entities belong. 



1 38. The system for supporting management of a collaborative activity set forth in claim 

2 37 wherein: 

3 the model entity types further include a domain model entity type, model entities 

4 of the type serving to relate goal hierarchies across the model; and 

5 the hierarchies further include a domain hierarchy whose members include at least 

6 one domain model entity, each in domain model entity being capable of having as 

7 children one or more domain model entities and/or one or more goal hierarchies. 
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1 39, The system for supporting management of a collaborative activity set forth in claim 

2 37 wherein: 

3 the graphical user interface provides a display having a first part in which the 

4 model entities of the hierarchy are viewed and a simultaneously visible second part in 

5 which a model entity selected by the user from the hierarchy is viewed. 



1 40. The system for supporting management of a collaborative activity set forth in claim 

2 37 wherein: 

3 any of the model entities is capable of providing access to information concerning 

4 the collaborative activity. 

1 41. The system for supporting management of a collaborative activity set forth in claim 

2 37 wherein the system further comprises: 

3 access control information accessible to the processor, the access control 

4 information controlling access by individual ones of the persons to individual ones of the 

5 model entities, 

6 the operations which the graphical user interface performs for a given person on a 

7 given model entity are determined by the access control information for the given person 

8 and the given model entity; and 

9 the operations which the graphical user interface will perform include controlling 
10 access to the model entity. 

1 42. The system for supporting management of a collaborative activity set forth in claim 

2 37 wherein: 

3 the operations which the graphical user interface performs includes viewing 

4 model entities as ordered by a value in the information concerning the collaborative 

5 activity to which the model entities give access. 

1 43. A data storage device, the data storage device being characterized in that: 

2 the data storage device contains a program which, when executed in a computer 

3 system, implements the system set forth in claim 37. 
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(9) Evidence appendix 

(None) 

(10) Related proceedings appendix 

(None) 



